-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8352426: RelocIterator should correctly handle nullptr address of relocation data #24203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
👋 Welcome back bulasevich! A progress list of the required criteria for merging this PR into |
|
@bulasevich This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 122 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
|
@bulasevich The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
|
This looks OK, but it is still a work-around because RelocIterator forces us to write loops like this: instead of the more modern range-for loop: |
@dean-long RelocIterator iter(nm, instruction_address(), next_instruction_address());
while (iter.next()) {
if (iter.type() == relocInfo::oop_type) {
oop* oop_addr = iter.oop_reloc()->oop_addr();
*oop_addr = cast_to_oop(x);
break;
} else if (iter.type() == relocInfo::metadata_type) {
Metadata** metadata_addr = iter.metadata_reloc()->metadata_addr();
*metadata_addr = (Metadata*)x;
break;
}
} |
|
This change addresses the bug reported in JDK-8352426 by ensuring that a nullptr relocation table does not result in undefined behavior. RelocIterator isn’t a simple iterator - it encapsulates a variety of functions beyond just iteration. Reworking the API to support a range-based for loop would require a significant redesign of its interface and behavior. In my opinion, such a rework is beyond the scope of JDK-8352426. If the goal is to modernize the RelocIterator API, including support for range-based for loops, we should either explicitly reformulate JDK-8352426 to include that broader scope, or better yet, create a separate JBS issue to track that as an independent refactoring. What do you think? |
|
I agree with @bulasevich that rewriting RelocIterator is out of scope of this RFE. And I am not sure that we should rewrite it at all. |
|
I submitted out testing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. I wasn't try to suggest that we need to rewrite RelocIterator now to support C++ iterators, but that that kind of interface could avoid the "nullptr - 1" issue, because then the iterator's begin() and end() functions would both return nullptr, and iteration would end because begin() == end().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My testing passed.
|
Good. Thanks for testing. And thanks all for the review! |
|
/integrate |
|
Going to push as commit 0bfa636.
Your commit was automatically rebased without conflicts. |
|
@bulasevich Pushed as commit 0bfa636. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
This is a follow-up to the recent #24102 patch. It addresses an issue where RelocIterator may receive a nullptr as the relocation table address. This change can also serve as an independent fix for JDK-8352112.
RelocIterator::initialize() and RelocIterator::next() perform decrement/increment operations on an internal relocaction pointer.
If nm->relocation_begin() returns nullptr, this results in undefined behavior, as pointer arithmetic on nullptr is prohibited by the C++ Standard.
Instead of introducing a null-check (which would add overhead in RelocIterator::next(), a performance-sensitive path), we initialize _current with a dummy static variable. This pointer is never dereferenced, so its actual value is not important - it just serves to avoid undefined behavior.
RelocIterator::RelocIterator constructor can initialize _current pointer as well. However, in that place we have an assert to ensure that nullptr value is not allowed, and it seems we do not need to apply dummy value there.
Testing:
The fix has been verified against the failure in JDK-8352112. The issue no longer reproduces with this patch, regardless of whether the original fix from #24102 is applied.
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/24203/head:pull/24203$ git checkout pull/24203Update a local copy of the PR:
$ git checkout pull/24203$ git pull https://git.openjdk.org/jdk.git pull/24203/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 24203View PR using the GUI difftool:
$ git pr show -t 24203Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/24203.diff
Using Webrev
Link to Webrev Comment